A load balancing method to support spatial analysis in XML/GML/SVG-based WebGIS

This chapter aims at introducing method for load balancing spatial analysis into XML/GML/SVG-based WebGIS. We propose that the decision on where to execute spatial query operations (server side or browser side) should be based on the network communication cost versus the computational cost. This chapter mainly focuses on the network communication cost. After analyzing the workflow of spatial analysis, we address the following issues: GML (server side)/SVG (browser side) -based spatial information representation, spatial query language, and load balancing middlewares for dispensing spatial queries to either server side or browser side. Finally, we design some case studies to evaluate the proposed method. The results prove that the method is feasible and operable to support spatial analysis in the Web environment, and has a better performance compared to the server side solution and the browser side solution. The method enables users to access spatial analysis functions simply with a web browser with SVG support. tions (Jeong et al. 2006), etc. However, most of the WebGIS applications, especially XML/GML/SVG-based WebGIS applications, have been designed for visualization (web mapping) only, and “avoid the access to spatial analysis functions” such as spatial topological queries, map overlay, and buffer analysis that are vital to spatial information applications (Lin & Huang 2001). When performing spatial analysis tasks, we often install corresponding GIS software (e.g., ESRI’s ArcGIS) on our computer, and carry out the tasks in a stand-alone or Local Area Network (LAN) environment. In the meantime, these applications only support their own spatial data formats. There are also some WebGIS applications which carry out all the spatial analysis tasks on the server side and then send the results to the browser side for visualization. These server-side solutions, sometimes, become impractical, as the server cannot handle a large volume of concurrent users. In order to solve this “bottleneck” problem, some of them introduce load balancing technology to the server side, which dispenses users’ spatial queries and analysis requests to different servers in a server cluster (Supermap 2010, Qin & Li 2007, Luo et al. 2003, Wang et al. 2004). However, spatial analysis is a complex process; users often have to try different queries before they are satisfied with the results. Since every query may result in a large volume of data (such as intermediate results which users may not need), there will be a high transmission overload between the server side and the web browser side when using this server-side solution. As such, in order to improve the performance, not all the spatial operations should be implemented on the server side. For example, as the “buffer” operation often results in more data output than input, it may be implemented on the browser side in order to reduce the network transmission load. Recognizing these limitations, this chapter proposes that in order to meet the increasing need of spatial information application in the web environment, spatial analysis based on load balancing technology should be introduced into XML/GML/SVG-based WebGIS. Load balancing spatial analysis carries out spatial queries and analyses either on the server side or the browser side depending on the network communication cost versus the computational cost. However, little work has been done on this aspect. The objective of this chapter is to introduce method for load balancing spatial analysis into XML/GML/SVG-based WebGIS. After analyzing the workflow of spatial analysis (defining the goal and evaluation criteria, representing the needed geospatial data, carrying out spatial query and analysis with GIS tools, and result appraisal and explanation), we focus on the following three key issues: GML (server side)/SVG (browser side) –based spatial information representation, spatial operators and spatial query language for both server side (for GML) and browser side (for SVG), and load balancing middlewares for dispensing spatial operations to the server side or the browser side. With the method, users can easily carry out spatial analysis tasks in the Web environment. Having provided a background to load balancing spatial analysis, the rest of this chapter is structured as follows. In Section 2, we analyze the workflow of spatial analysis, and identify the key issues of introducing spatial analysis into XML/GML/SVG-based WebGIS. Section 3 uses the theory of spatial data modeling to design GML/SVG-based spatial information representation models. Based on the representation models, we design some spatial operators and a spatial extended SQL (SSESQL) to support spatial query and analysis directly on GML/SVG in Section 4. Section 5 describes the load balancing middlewares. Some case studies are implemented to evaluate the method in Section 6. Finally, Section 7 draws the conclusions and presents the future work. 2 WORKFLOW OF SPATIAL ANALYSIS Spatial analysis is “a set of methods whose results change when the locations of the objects being analyzed change” (Longley et al. 2005, p.217). It plays a key role in GIS. According to Wu (2002), the workflow of spatial analysis includes four steps: 1) defining the goal and evaluation criteria; 2) representing the needed spatial dataset; 3) carrying out spatial query and analysis with GIS tools; and 4) result appraisal and explanation. Steps 1 and 4 require domain knowledge and are mainly carried out by domain experts. For step 2 and step 3, GIS tools are needed to support and assist human-computer interaction. Figure 1 depicts the workflow of spatial analysis. Figure 1. Workflow of spatial analysis. The chapter mainly focuses on designing method to support and assist step 2 and step 3. For step 2, we design GML/SVG-based spatial information representation models which can be used to represent the needed spatial datasets in GML and SVG (Section 3). For step 3, we design and implement some spatial operators and integrate them into an SVG-based Spatial Extended SQL (SSESQL) to support spatial query and analysis on spatial datasets represented in GML and SVG (Section 4). In order to improve the performance, we also introduce load balancing middlewares to reduce the network transmission load (Section 5). However, the load balancing middlewares are completely transparent to the end users. 3 SPATIAL DATA MODELING FOR SVG/GML-BASED SPATIAL INFORMATION REPRESENTATION In this section, we employ the theory of spatial data modeling to design SVG/GML-based spatial information representation models for representing spatial data on both server side and browser side. 3.1 SVG-based spatial information representation model In Huang et al. (2008), we set up a theoretical framework for SVG-based spatial information representation based on the theory of spatial data modeling, which includes three steps: 1) choosing a conceptual model which can abstract the real world most appropriately, 2) choosing a suitable data structure to represent the conceptual model, and 3) designing a file format, or an appropriate method to record or store the data structure in Step 2. Based on that theoretical framework, Huang et al. (2008) adapted the OGC’s Geometry Object Model (GOM) (OGC 1999), and developed an SVG-based spatial information representation model (Fig. 2). In this model, we use element to represent Map (the dataset), and use viewBox attribute to represent its bounded range. Layer is represented as element. Point, Curve, Surface are represented as , , and , respectively. element is used to represent the Multipoint, Multicurve, Multisurface and Multigeometry. Both spatial and non-spatial attributes of spatial objects are represented as corresponding SVG element’s attributes. In the model, if B is PART-OF A (i.e., composition/aggregation relationship), B is represented as a child element of A. For example, Layer is PART-OF Map, so element which represents Layer is a child element of element which represents Map. With this model, users can use SVG to represent the needed spatial information. Figure 6 illustrates an example of such representation. Figure 2. SVG-based spatial information representation model. 3.2 GML-based spatial information representation model Similar to our SVG-based representation model, we developed a GML-based spatial information representation model (Fig. 3) (Huang & Li 2009). Figure 3. GML-based spatial information representation model. In this model, we use GML “FeatureCollection” element to represent the Map (dataset), and use “boundedBy” and “srsName” to represent the bounded area and spatial coordinate system of the Map. Layer is represented as element which is inherited from “gml:_Feature”. If B is PART-OF A (composition relationship in Fig. 3), B is represented as a child element of B. Both spatial attributes and non-spatial attributes are represented as the child elements of the corresponding GML elements. 3.3 Transformation from GML to SVG By using the models depicted in Figures 2-3, users can easily use GML/SVG to represent the needed spatial data on both the server side and the browser side. Because they are based on the same conceptual model and spatial data structure (logical model), GML-based spatial datasets on the server side can be easily and losslessly converted to SVG-based datasets for the browser side. Table 1 compares the different elements/attributes in the GML and SVG-based spatial information representation models. Table 1. Comparison of GML and SVG-based spatial information representation models. ______________________________________________________________________________________ Description GML elements SVG elements/ attributes ______________________________________________________________________________________ Map FeatureCollection svg Bounded area of the map boundedBy/ Envelope viewBox Point object Point circle Curve object LineString path Polygon object Polygon path (end with “Z”) Compound object MultiPoint, MultiLine, g MultiPolygon, MultiGeometry ______________________________________________________________________________________ When transforming GML datasets to SVG datasets for visualization, we should also make some transformation to the coordinate systems in GML. Figure 4 compares the differences between the coordinate systems used in GML and SVG. Therefore, if we do not make any transformation to the coordinate systems, the map represented in SVG may become headstand. Figure 4. Comparison of the coordinate systems of GML and SVG. We use SVG’s “translate” attribute to implement this transformation. The transformation parameter is set as “translate (0, 2*min_y + height), scale(1,-1)”, where (min_x, min_y, width, height) represents the bounded area of the map, and can be found in the “viewBox” attribute of the root “SVG” element. Because all the layers have to be translated to avoid headstand, we use element to group all the layers together. Figure 5. An SVG map of Guangdong province with two layers (gd_river_line and gd_city_polygon) Figure 5 shows a map of Guangdong province (China) represented in SVG. We use Internet Explorer with SVG plug-in to visualize the map. The map includes two layers: gd_river_line and gd_city_polygon. In Figure 6, we compare the GML and SVG codes which represent the map using our suggested models (Figs 2-3). The code “” in Figure 6 also gives an example about the transformation of the coordinate systems. Figure 6. Comparison of codes in GML and SVG. 4 SPATIAL OPERATORS AND SSESQL This section focuses on how to carry out spatial data query on GML and SVG. It is important to note that XQuery is often employed to query XML-based data, and is also suitable for querying GML/SVG data. However, XQuery has a very special and complicated syntax, and has not become familiar to many people. In contrast, SQL (Structured Query Language) has a relative simple and intuitive syntax, and has been familiar to many technical users. More importantly, SQL is more powerful in querying data. Thus, in consideration of end users’ acceptance and the processing capabilities of SQL, an extended SQL is employed for spatial data query on GML and SVG. Several efforts have been made, attempting to make spatial extensions to SQL (Lin & Huang 2001, Egenhofer 1994). These extended SQL introduce spatial data types (e.g., point, line and polygon) and spatial operators, allowing users to inquire spatial features, primarily in terms of spatial relationships and metric constraints (Lin & Huang 2001). It is widely acknowledged that these spatial operators and SQL like languages can be used for spatial analysis (Frank 1984). According to Section 3, spatial information is organized as “map layer spatial object” structure. A map represented by SVG/GML can be viewed as a database, the layers as tables of the database, the attributes (spatial and non-spatial) of spatial objects in a layer as columns of the corresponding table, and spatial objects as records of the corresponding table. Thus SQL like languages can be used for spatial query and analysis on SVG and GML. In this section, we design some spatial operators and integrate them into an SVG-based Spatial Extended SQL (SSESQL). The SSESQL uses the basic spatial data types discussed in Section 3: Point, Curve, Surface, Multipoint, Multicurve, Multisurface and Multigeometry. It can be used on both server side and browser side for spatial query and analysis on GML and SVG. 4.1 Spatial operators Spatial operators are mainly designed to access spatial attributes, calculate spatial relationships, and perform geometrical operations. We introduce five types of operators: attribute access operators (GeometryType, Centroid, Length, Area, and Envelope), spatial topological operators (Disjoint, Touch, Crosses, Within, Overlap, and Contain), spatial order operators (East, East_South, South, West_South, West, West_North, North, and East_North), spatial metric operators (Max_Dist, Min_Dist, and Mean_Dist), and geometrical operators (Intersection, Union, Difference, and Buffer). These five types of operators can meet the basic needs of spatial analysis. For network analysis, we can use Touch operator and Length operator to find out the touched spatial object (e.g., road) and the distance. We can use Buffer operator and topological operators to carry out buffer analysis, such as “which cities are around 100km of the Danube River”. Also, we can use Intersection, Union and Difference operators to carry out overlay analysis. It is important to note that, the above spatial operators can be used as APIs (Application Programming Interface) and integrated into other programs. However, we integrate them into a SVG-based Spatial Extended SQL (SSESQL) to support end users’ interaction. More detail of the spatial operators can be found in Huang et al. (2008). 4.2 SSESQL and some query examples As SSESQL is designed for spatial query, there is no need to consider data insert, update and delete. As a result, we integrate the above spatial operators to the original SELECT clause of SQL. The EBNF (Extended Backus-Naur Form) of SELECT clause of SSESQL can be found in Huang et al. (2008). The following are some query examples. The two layers represented in the Figures 5-6 can be viewed as the following tables: gd_city_polygon (ID, population, d) and gd_river_line (ID, length, d) in Figure 7. Figure 7. Tables of gd_city_polygon and gd_river_line shown in Microsoft Access. 1) Query example 1: Lists the neighbor cities of city “C1”. SELECT city1.ID AS Neighbors_of_C1 FROM gd_city_polygon city1, gd_city_polygon city2 WHERE Touch (city1.d, city2.d)=True AND city2.ID=’C1’ 2) Query example 2: Lists the cities which are crossed by the river “R1”. SELECT c.id AS cid FROM gd_river_line r, gd_city_polygon c WHERE r.id=”R1” AND Crosses(r.d, c.d)=True; 3) Query example 3: There is some toxic contamination throughout the River “R1”. This toxic contamination affects the cities, which are 100km around the river. Please list all affected cities. SELECT c.id FROM gd_river_line r, gd_city_polygon c WHERE Overlap(c.d, Buffer(r.d, 100000))=True AND r.id=”R1”; Since the GML-based spatial information representation model uses the same conceptual model and spatial data structure (logical model) as the SVG-based spatial information representation model, we can also apply the SSESQL to carry out spatial queries and analyses on GMLbased spatial data on the server side. The only difference in applying SSESQL for spatial analysis on SVG and GML is the implementation of the SSESQL compiler. 5 LOAD BALANCING MIDDLEWARES In this section, we focus on designing the load balancing middlewares to dispense a spatial query to either the server side or the browser side based on the cost of that spatial query. 5.1 General principle The general principle of the load balancing algorithm is to compare the costs of server side solution (Cserver) and browser side solution (Cbrowser). If Cserver is less than Cbrowser, execute the spatial query on the server side, and send the result data to the browser. Otherwise, send the data (input data) to the browser, and carry out the spatial query on the browser side. The cost of a spatial query includes the computational cost (execution of the spatial query) and network transmission cost (input data and output data of spatial operations) and both of them are often measured by delay. As a normal PC’s processor performance has been drastically improved, the difference between the server side and the browser side’s computational cost becomes minimal or less significant for most of the spatial queries. Therefore, the difference between Cserver and Cbrowser mainly depends on the network transmission cost. Our discussions below will focus on comparing the network transmission cost.